Apparatus and Method for Combining Realtime and Non-Realtime Encoded Content

ABSTRACT

A terminal for decoding and presenting encoded realtime and non-realtime interactive program guide (IPG) content including a realtime video portion and a non-realtime guide graphics portion. The terminal includes a demodulator operative to receive and demodulate a modulated signal to provide a transport stream, and a transport demultiplexer coupled to the demodulator and operative to receive and process the transport stream to provide a sequence of transport packets re-timestamped to synchronize encoded realtime content and encoded non-realtime content included therein. At least one video decoder is coupled to the transport demultiplexer and operative to receive and decode the encoded realtime and non-realtime contents to recover the realtime and non-realtime contents for the user interface.

CROSS-REFERENCES TO RELATED APPLICATIONS

The present application is a continuation of U.S. patent applicationSer. No. 10/936,183, filed Sep. 8, 2004, which is a continuation of U.S.patent application Ser. No. 09/458,796, filed Dec. 9, 1999 (now U.S.Pat. No. 7,096,487, issued Aug. 22, 2006), which is acontinuation-in-part of U.S. patent application Ser. No. 09/428,066,filed Oct. 27, 1999 (now U.S. Pat. No. 6,651,252, issued Nov. 18, 2003),the contents of which are hereby incorporated by reference in theirentities.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates to communications systems in general and, morespecifically, the invention relates to a multi-functional user interfaceand related encoding techniques for use in an interactive multimediainformation delivery system.

2. Description of the Background Art

Over the past few years, the television industry has seen atransformation in a variety of techniques by which its programming isdistributed to consumers. Cable television systems are doubling or eventripling system bandwidth with the migration to hybrid fiber coax (HFC)cable transmission systems. Customers unwilling to subscribe to localcable systems have switched in high numbers to direct broadcastsatellite (DBS) systems. And, a variety of other approaches have beenattempted focusing primarily on high bandwidth digital technologies,intelligent two way set top boxes, or other methods of attempting tooffer service differentiated from standard cable and over the airbroadcast systems.

With this increase in bandwidth, the number of programming choices hasalso increased. Leveraging off the availability of more intelligent settop boxes, several companies have developed elaborate systems forproviding an interactive listing of a vast array of channel offerings,expanded textual information about individual programs, the ability tolook forward to plan television viewing as much as several weeks inadvance, and the option of automatically programming a video cassetterecorder (VCR) to record a future broadcast of a television program.

Unfortunately, the existing program guides have several drawbacks. Theytend to require a significant amount of memory, some of them needingupwards of one megabyte of memory at the set top terminal (STT). Theyare very slow to acquire their current database of programminginformation when they are turned on for the first time or aresubsequently restarted (e.g., a large database may be downloaded to aSTT using only a vertical blanking interval (VBI) data insertiontechnique). Disadvantageously, such slow database acquisition may resultin out-of-date database information or, in the case of a pay-per-view(PPV) or video-on-demand (VOD) system, limited scheduling flexibilityfor the information provider.

In addition, existing program guides with point-to-point deliverymechanisms suffer linear decay in response time with respect to thenumber of subscribers served. The response time starts in the sub-secondrange with a handful of subscribers but seems to quickly exceed 3seconds as the number of subscribers extends into the low thousands (2to 4 thousand).

Another point of concern is the still-based, banner and audio(radio-style) advertisements (ads) in current program guides. These adsrequire different production and delivery methods from standard cableadvertising practice. This practically precludes the operator fromdirectly capitalizing on this capability due to the costs of maintaininga distinct and separate infrastructure to support the required methods.And, the value of still-based and banner ads is far less than fullmotion ads.

Existing program guides generally have only a single video content to beshared among many guide pages. Features such as multiple different videocontent (e.g., picture-in-picture (PIP)), are not supported in existingprogram guides on single tuner set top boxes. Within this context, PIPrefers to user interface screen that may carry one or more differentvideo content. Existing program guides lack support for fully functionalelectronic commerce and video on-demand application interfaces. Forintegration with future applications, an extensible interactive systemis required with its ability to integrate with multiple sources offull-motion video and play them interchangeably from a single tuner inthe set top box, to open up a world of possible applications in theareas of interactive shopping, internet-enhanced television and otherreal-time information services.

Therefore, it is desirable to provide an efficient interactivemultimedia delivery system which provides encoding, multiplexing,demultiplexing to enable multiple video streams within a program guideand to support electronic commerce and other applications with amulti-functional user interface.

SUMMARY. OF THE INVENTION

The present invention overcomes problems and drawbacks relating tomultiplexing realtime and non-realtime encoded content for distributionto set-top terminals. An apparatus for encoding a transport stream inaccordance with the present invention includes: a non-realtime contentsource for providing non-realtime content; a non-realtime encoder forencoding the non-realtime content into encoded non-realtime content; arealtime content source for providing realtime video and audio content;a realtime encoder for encoding the realtime video and audio contentinto encoded realtime video and audio; a remultiplexer for repacketizingthe encoded non-realtime content and the encoded realtime video andaudio into transport packets; and a re-timestamp unit coupled to theremultiplexer for providing timestamps to be applied to the transportpackets in order to synchronize the realtime and non-realtime contenttherein.

The present invention also provides a terminal (i.e., set-top-terminal)for decoding and presenting encoded realtime and non-realtimeinteractive program guide (IPG) content including a realtime videoportion and a non-realtime guide graphics portion. The terminal includesa demodulator operative to receive and demodulate a modulated signal toprovide a transport stream, and a transport demultiplexer coupled to thedemodulator and operative to receive and process the transport stream toprovide a sequence of transport packets re-timestamped to synchronizeencoded realtime content and encoded non-realtime content includedtherein. At least one video decoder is coupled to the transportdemultiplexer and operative to receive and decode the encoded realtimeand non-realtime contents to recover the realtime and non-realtimecontents for the user interface.

BRIEF DESCRIPTION OF THE DRAWINGS

The teachings of the present invention can be readily understood byconsidering the following detailed description in conjunction with theaccompanying drawings, in which:

FIG. 1 depicts an example of one frame of an interactive program guide(IPG) taken from a video sequence that can be encoded using the presentinvention;

FIG. 2 depicts a block diagram of an illustrative interactiveinformation distribution system that includes the encoding unit andprocess of the present invention;

FIG. 3 depicts a slice map for the IPG of FIG. 1;

FIG. 4 depicts a block diagram of the encoding unit of FIG. 2;

FIG. 5 depicts a block diagram of the local neighborhood network of FIG.2;

FIG. 6 depicts a matrix representation of program guide data with thedata groupings shown for efficient encoding in accordance with thepresent invention;

FIG. 7 is a diagrammatic flow diagram of a process for generating aportion of transport stream containing intra-coded video and graphicsslices;

FIG. 8 is a diagrammatic flow diagram of a process for generating aportion of transport stream containing predictive-coded video andgraphics slices;

FIG. 9 illustrates a data structure of a transport stream used totransmit the IPG of FIG. 1;

FIG. 10 is a diagrammatic flow diagram of a alternative process forgenerating a portion of transport stream containing predictive-codedvideo and graphics slices;

FIG. 11A depicts an illustration of an IPG having a graphics portion anda plurality of video portions;

FIG. 11B depicts a slice map for the IPG of FIG. 11A;

FIG. 12 is a diagrammatic flow diagram of a process for generating aportion of transport stream containing intra-coded video and graphicsslices for an IPG having a graphics portion and a plurality of videoportions;

FIG. 13 is a diagrammatic flow diagram of a process for generating aportion of transport stream containing predictive-coded video andgraphics slices for an IPG having a graphics portion and a plurality ofvideo portions;

FIG. 14 depicts a block diagram of a receiver within subscriberequipment suitable for use in an interactive information distributionsystem;

FIG. 15 depicts a flow diagram of a first embodiment of a slicerecombination process;

FIG. 16 depicts a flow diagram of a second embodiment of a slicerecombination process;

FIG. 17 depicts a flow diagram of a third embodiment of a slicerecombination process;

FIG. 18 depicts a flow diagram of a fourth embodiment of a slicerecombination process;

FIG. 19 is a schematic diagram illustrating slice-based formation of anintra-coded portion of a stream of packets including multipleintra-coded guide pages and multiple intra-coded video signals inaccordance with an embodiment of this invention;

FIG. 20 is a schematic diagram illustrating slice-based formation of avideo portion of predictive-coded stream of packets including multiplepredictive-coded video signals in accordance with an embodiment of thisinvention;

FIG. 21 is a schematic diagram illustrating slice-based formation of aguide portion of predictive-coded stream of packets including skippedguide pages in accordance with an embodiment of this invention;

FIG. 22 is a block diagram illustrating a system and apparatus formultiplexing various packet streams to generate a transport stream inaccordance with an embodiment of this invention;

FIG. 23 is a schematic diagram illustrating slice-based partitioning ofmultiple objects in accordance with an embodiment of this invention;

FIG. 24 is a block diagram illustrating a cascade compositor forresizing and combining multiple video inputs to create a single videooutput which may be encoded into a video object stream in accordancewith an embodiment of this invention;

FIG. 25 is a block diagram illustrating a system and apparatus formultiplexing video object and audio streams to generate a transportstream in accordance with an embodiment of this invention;

FIG. 26 is a block diagram illustrating a system and apparatus fordemultiplexing a transport stream to regenerate video object and audiostreams for subsequent decoding in accordance with an embodiment of thisinvention;

FIG. 27 is a schematic diagram illustrating interacting with objects byselecting them to activate a program guide, an electronic commercewindow, a video on-demand window, or an advertisement video inaccordance with an embodiment of this invention;

FIG. 28 is a schematic diagram illustrating interacting with an objectby selecting it to activate a full-resolution broadcast channel inaccordance with an embodiment of this invention;

FIG. 29 is a flow chart illustrating an object selection operation inaccordance with an embodiment of this invention;

FIG. 30 is a schematic diagram illustrating PID filtering prior to slicerecombination in accordance with an embodiment of this invention; and

FIG. 31 is a schematic diagram illustrating slice recombination inaccordance with an embodiment of this invention.

FIG. 32 is a block diagram illustrating a general head-end centricsystem to encode and deliver a combined real time and non-real timemultimedia content.

To facilitate understanding, identical reference numerals have beenused, where possible, to designate identical elements that are common tothe figures.

DESCRIPTION OF THE SPECIFIC EMBODIMENTS

This invention is a system for generating, distributing and receiving atransport stream containing compressed video and graphics information.The invention is illustratively used to encode a plurality ofinteractive program guides (IPGs) that enable a user to interactivelyreview, preview and select programming for a television system.

The invention uses compression techniques to reduce the amount of datato be transmitted and increase the speed of transmitting program guideinformation. As such, the data to be transmitted is compressed so thatthe available transmission bandwidth is used more efficiently. Totransmit an IPG having both graphics and video, the invention separatelyencodes the graphics from the video such that the encoder associatedwith each portion of the IPG can be optimized to best encode theassociated portion. The invention illustratively uses a slice-based,predictive encoding process that is based upon the Moving PicturesExperts Group (MPEG) standard known as MPEG-2. MPEG-2 is specified inthe ISO/EEC standards 13818, which is incorporated herein by reference.

The above-referenced standard describes data processing and manipulationtechniques that are well suited to the compression and delivery ofvideo, audio and other information using fixed or variable rate digitalcommunications systems. In particular, the above-referenced standard,and other “MPEG-like” standards and techniques, compress,illustratively, video information using intra-frame coding techniques(such as run-length coding, Huffman coding and the like) and inter-framecoding techniques (such as forward and backward predictive coding,motion compensation and the like). Specifically, in the case of videoprocessing systems, MPEG and MPEG-like video processing systems arecharacterized by prediction-based compression encoding of video frameswith or without intra- and/or inter-frame motion compensation encoding.

To enhance error recovery, the MPEG-2 standard contemplates the use of a“slice layer” where a video frame is divided into one or more slices. Aslice contains one or more contiguous sequence of macroblocks. Thesequence begins and ends at any macroblock boundary within the frame. AnMPEG-2 decoder, when provided a corrupted bitstream, uses the slicelayer to avoid reproducing a completely corrupted frame. For example, ifa corrupted bitstream is decoded and the decoder determines that thepresent slice is corrupted, the decoder skips to the next slice andbegins decoding. As such, only a portion of the reproduced picture iscorrupted.

The present invention uses the slice layer for the main purpose offlexible encoding and compression efficiency in a head end centricend-to-end system. A slice-based encoding system enables the graphicsand video of an IPG to be efficiently coded and flexibly transmitted asdescribed below. Consequently, a user can easily and rapidly move fromone IPG page to another IPG page.

A. An Exemplary Interactive Program Guide

The present invention can be employed for compressing and transmittingvarious types of video frame sequences that contain graphics and videoinformation, and is particularly useful in compressing and transmittinginteractive program guides (IPG) where a portion of the IPG containsvideo (referred to herein as the video portion) and a portion of the IPGcontains a programming guide grid (referred to herein as the guideportion or graphics portion). The present invention slice-based encodesthe guide portion separately from the slice-based encoded video portion,transmits the encoded portions within a transport stream, andreassembles the encoded portions to present a subscriber (or user) witha comprehensive IPG. Through the IPG, the subscriber can identifyavailable programming and select various services provided by theirinformation service provider.

FIG. 1 depicts a frame from an illustrative IPG page 100. In thisparticular embodiment of an IPG, the guide grid information is containedin portion 102 (left half page) and the video information is containedin portion 101 (right half page). The IPG display 100 comprises a first105A, second 105B and third 105C time slot objects, a plurality ofchannel content objects 110-1 through 110-8, a pair of channel indicatoricons 141A, 141B, a video barker 120 (and associated audio barker), acable system or provider logo 115, a program description region 150, aday of the week identification object 131, a time of day object 139, anext time slot icon 134, a temporal increment/decrement object 132, a“favorites” filter object 135, a “movies” filter object 136, a “kids”(i.e., juvenile) programming filter icon 137, a “sports” programmingfilter object 138 and a VOD programming icon 133. It should be notedthat the day of the week object 131 and next time slot icon 134 maycomprise independent objects (as depicted in FIG. 1) or may beconsidered together as parts of a combined object.

A user may transition from one IPG page to another, where each pagecontains a different graphics portion 102, i.e., a different programguide graphics. The details regarding the encoding and decoding of aseries of IPG pages in accordance with the present invention areprovided below.

Details regarding the operation of the IPG page of FIG. 1, theinteraction of this page with other pages and with a user are describedin commonly assigned U.S. patent application Ser. No. 09/359,560 filedJul. 22, 1999 (attorney docket no. 070 CIP2) which is herebyincorporated herein by reference.

B. System

FIG. 2 depicts a high-level block diagram of an information distributionsystem 200, e.g., a video-on-demand system or digital cable system thatincorporates the present invention. The system 200 contains head endequipment (HEE) 202, local neighborhood equipment (LNE) 228, adistribution network 204 (e.g., hybrid fiber-coax network) andsubscriber equipment (SE) 206. This form of information distributionsystem is disclosed in commonly assigned U.S. Pat. No. 6,253,375. Thesystem is known as DIVATM provided by DIVA Systems Corporation.

The HEE 202 produces a plurality of digital streams that contain encodedinformation in illustratively MPEG-2 compressed format. These streamsare modulated using a modulation technique that is compatible with acommunications channel 230 that couples the HEE 202 to one or more LNE(in FIG. 1, only one LNE 228 is depicted). The LNE 228 is illustrativelygeographically distant from the HEE 202. The LNE 228 selects data forsubscribers in the LNE's neighborhood and remodulates the selected datain a format that is compatible with distribution network 204. Althoughthe system 200 is depicted as having the HEE 202 and LNE 228 as separatecomponents, those skilled in the art will realize that the functions ofthe LNE may be easily incorporated into the HEE202. It is also importantto note that the presented slice-based encoding method is notconstrained to physical location of any of the components. Thesubscriber equipment (SE) 206, at each subscriber location 2061, 2062, .. . , 206 n, comprises a receiver 224 and a display 226. Upon receivinga stream, the subscriber equipment receiver 224 extracts the informationfrom the received signal and decodes the stream to produce theinformation on the display, i.e., produce a television program, IPGpage, or other multimedia program.

In an interactive information distribution system such as the onedescribed in commonly assigned U.S. Pat. No. 6,253,375, the programstreams are addressed to particular subscriber equipment locations thatrequested the information through an interactive menu. A relatedinteractive menu structure for requesting video-on-demand is disclosedin commonly assigned U.S. Pat. No. 6,208,335. Another example ofinteractive menu for requesting multimedia services is the interactiveprogram guide (IPG) disclosed in commonly assigned U.S. patentapplication 60/093,891, filed in Jul. 23, 1998.

To assist a subscriber (or other viewer) in selecting programming, theHEE 202 produces information that can be assembled to create an IPG suchas that shown in FIG. 1. The HEE produces the components of the IPG asbitstreams that are compressed for transmission in accordance with thepresent invention.

A video source 214 supplies the video sequence for the video portion ofthe IPG to an encoding unit 216 of the present invention. Audio signalsassociated with the video sequence are supplied by an audio source 212to the encoding and multiplexing unit 216. Additionally, a guide datasource 232 provides program guide data to the encoding unit 216. Thisdata is typically in a database format, where each entry describes aparticular program by its title, presentation time, presentation date,descriptive information, channel, and program source.

The encoding unit 216 compresses a given video sequence into one or moreelementary streams and the graphics produced from the guide data intoone or more elementary streams. As described below with respect to FIG.4, the elementary streams are produced using a slice-based encodingtechnique. The separate streams are coupled to the cable modem 222.

The streams are assembled into a transport stream that is then modulatedby the cable modem 222 using a modulation format that is compatible withthe head end communications channel 230. For example, the head endcommunications channel may be a fiber optic channel that carries highspeed data from the HEE 202 to a plurality of LNE 228. The LNE 228selects IPG page components that are applicable to its neighborhood andremodulates the selected data into a format that is compatible with aneighborhood distribution network 204. A detailed description of the LNE228 is presented below with respect to FIG. 5.

The subscriber equipment 206 contains a receiver 224 and a display 226(e.g., a television). The receiver 224 demodulates the signals carriedby the distribution network 204 and decodes the demodulated signals toextract the IPG pages from the stream. The details of the receiver 224are described below with respect to FIG. 14.

C. Encoding Unit 216

The system of the present invention is designed specifically to work ina slice-based ensemble encoding environment, where a plurality ofbitstreams is generated to compress video information using asliced-based technique. In the MPEG-2 standard, a “slice layer” may becreated that divides a video frame into one or more “slices”. Each sliceincludes one or more macroblocks, where the macroblocks areillustratively defined as rectangular groups of pixels that tile theentire frame, e.g., a frame may consist of 30 rows and 22 columns ofmacroblocks. Any slice may start at any macroblock location in a frameand extend from left to right and top to bottom through the frame. Thestop point of a slice can be chosen to be any macroblock start or endboundary. The slice layer syntax and its conventional use in forming anMPEG-2 bitstream is well known to those skilled in the art and shall notbe described herein.

When the invention is used to encode an IPG comprising a graphicsportion and a video portion, the slice-based technique separatelyencodes the video portion of the IPG and the grid graphics portion ofthe IPG. As such, the grid graphics portion and the video portion arerepresented by one or more different slices. FIG. 3 illustrates anexemplary slice division of an IPG 100 where the guide portion 102 andthe video portion 101 are each divided into N slices (e.g., g/s1 throughg/sN and v/s1 through v/sN). Each slice contains a plurality ofmacroblocks, e.g., 22 macroblocks total and 11 macroblocks in eachportion. The slices in the graphics portion are pre-encoded to form a“slice form grid page” database that contains a plurality of encodedslices of the graphics portion. The encoding process can also beperformed real-time during the broadcast process depending on thepreferred system implementation. In this way, the graphics slices can berecalled from the database and flexibly combined with the separatelyencoded video slices to transmit the IPG to the LNE and, ultimately, tothe subscribers. The LNE assembles the IPG data for the neighborhood asdescribed below with respect to FIG. 5. Although the followingdescription of the invention is presented within the context of an IPG,it is important to note that the method and apparatus of the inventionis equally applicable to a broad range of applications, such asbroadcast video on demand delivery, e-commerce, interne video educationservices, and the like, where delivery of video sequences with commoncontent is required.

As depicted in FIG. 4, the encoding unit 216 receives a video sequenceand an audio signal. The audio source comprises, illustratively, audioinformation that is associated with a video portion in the videosequence such as an audio track associated with still or moving images.For example, in the case of a video sequence representing a movietrailer, the audio stream is derived from the source audio (e.g., musicand voice-over) associated with the movie trailer.

The encoding unit 216 comprises video processor 400, a graphicsprocessor 402 and a controller 404. The video processor 400 comprises acompositor unit 406 and an encoder unit 408. The compositor unit 406combines a video sequence with advertising video, advertiser or serviceprovider logos, still graphics, animation, or other video information.The encoder unit 408 comprises one or more video encoders 410, e.g., areal-time MPEG-2 encoder and an audio encoder 412, e.g., an AC-3encoder. The encoder unit 408 produces one or more elementary streamscontaining slice-based encoded video and audio information.

The video sequence is coupled to a real time video encoder 410. Thevideo encoder then forms a slice based bitstream, e.g., an MPEG-2compliant bit stream, for the video portion of an IPG. For purposes ofthis discussion, it is assumed that the GOP structure consists of anI-picture followed by ten B-pictures, where a P-picture separates eachgroup of two B-pictures (i.e., “I-B-B-P-B-B-P-B-B-P-B-B-P-B-B”),however, any GOP structure and size may be used in differentconfigurations and applications.

The video encoder 410 “pads” the graphics portion (illustratively theleft half portion of IPG) with null data. This null data is replaced bythe graphics grid slices, at a later step, within LNE. Since the videoencoder processes only motion video information, excluding the graphicsdata, it is optimized for motion video encoding.

The controller 404 manages the slice-based encoding process such thatthe video encoding process is time and spatially synchronized with thegrid encoding process. This is achieved by defining slice start and stoplocations according to the objects in the IPG page layout and managingthe encoding process as defined by the slices.

The graphics portion of the IPG is separately encoded in the graphicsprocessor 402. The processor 402 is supplied guide data from the guidedata source (232 in FIG. 2). Illustratively, the guide data is in aconventional database format containing program title, presentationdate, presentation time, program descriptive information and the like.The guide data grid generator 414 formats the guide data into a “grid”,e.g., having a vertical axis of program sources and a horizontal axis oftime increments. One specific embodiment of the guide grid is depictedand discussed in detail above with respect to FIG. 1.

The guide grid is a video frame that is encoded using a video encoder416 optimized for video with text and graphics content. The videoencoder 416, which can be implemented as software, slice-based encodesthe guide data grid to produce one or more bitstreams that collectivelyrepresent the entire guide data grid. The encoder is optimized toeffectively encode the graphics and text content.

The controller 404 defines the start and stop macroblock locations foreach slice. The result is a GOP structure having intra-coded picturescontaining I-picture slices and predicted pictures containing B andP-picture slices. The I-pictures slices are separated from the predictedpicture slices. Each encoded slice is separately stored in a slice formgrid page database 418. The individual slices can be addressed andrecalled from the database 418 as required for transmission. Thecontroller 404 controls the slice-based encoding process as well asmanages the database 418.

D. Local Neighborhood Equipment (LNE) 228

FIG. 5 depicts a block diagram of the LNE 228. The LNE 228 comprises acable modem 500, slice combiner 502, a multiplexer 504 and a digitalvideo modulator 506. The LNE 228 is coupled illustratively via the cablemodem to the HEE 202 and receives a transport stream containing theencoded video information and the encoded guide data grid information.The cable modem 500 demodulates the signal from the HEE 202 and extractsthe MPEG slice information from the received signal. The slice combiner502 combines the received video slices with the guide data slices in theorder in which the decoder at receiver side can easily decode withoutfurther slice re-organization. The resultant combined slices are PIDassigned and formed into an illustratively MPEG compliant transportstream(s) by multiplexer 504. The slice-combiner (scanner) andmultiplexer operation is discussed in detail with respect to FIGS. 5-10.The transport stream is transmitted via a digital video modulator 506 tothe distribution network 204.

The LNE 228 is programmed to extract particular information from thesignal transmitted by the HEE 202. As such, the LNE can extract videoand guide data grid slices that are targeted to the subscribers that areconnected to the particular LNE. For example, the LNE 228 can extractspecific channels for representation in the guide grid that areavailable to the subscribers connected to that particular LNE. As such,unavailable channels to a particular neighborhood would not be depictedin a subscriber's IPG. Additionally, the IPG can contain targetedadvertising, e-commerce, program notes, and the like. As such, each LNEcan combine different guide data slices with different video to produceIPG screens that are prepared specifically for the subscribers connectedto that particular LNE. Other LNEs would select different IPG componentinformation that is relevant to their associated subscribers.

FIG. 6 illustrates a matrix representation 600 of a series of IPG pages.In the illustrated example, ten different IPG pages are available at anyone time period, e.g., t1, t2, and so on. Each page is represented by aguide portion (g) and a common video portion (v) such that a first IPGpage is represented by g1/v1, the second IPG page is represented byg2/v1 and so on. In the illustrative matrix 600, ten identical guideportions (g1-g10) are associated with a first video portion (v1). Eachportion is slice-base encoded as described above within the encodingunit (216 of FIG. 4).

FIG. 6 illustrates the assignment of PIDs to the various portions of theIPG pages. In the figure, only the content that is assigned a HD isdelivered to a receiver. The intra-coded guide portion slices g1 throughg10 are assigned to PID1 through PID10 respectively. One of the commonintra-coded video portion v1, illustratively the tenth IPG page, isassigned to PID11. In this form, substantial bandwidth saving isachieved by delivering intra-coded video portion slices v1 only onetime. Lastly, the predictive-coded slices g1/v2 through g1/v15 areassigned to PID11. As shown in the figure, a substantial bandwidthsaving is achieved by transmitting only one group of illustrativelyfourteen predicted picture slices, g1/v2 to g1/v15. This is provided bythe fact that the prediction error images for each IPG page 1 to 10through time units t2 to t15 contain the same residual images. Furtherdetails of PID assignment process is discussed in next sections.

FIG. 7 depicts a process 700 that is used to form a bitstream 710containing all the intra-coded slices encoded at a particular time t1 ofFIG. 6. At step 702, a plurality of IPG pages 7021 through 70210 areprovided to the encoding unit. At step 704, each page is slice baseencoded to form, for example, guide portion slices g1/s1 through g1/sNand video portion slices v/s1 through v/sN for IPG page 1 7041. Theslice based encoding process for video and guide portions can beperformed in different forms. For example, guide portion slices can bepre-encoded by a software MPEG-2 encoder or encoded by the same encoderas utilized for encoding the video portion. If the same encoder isemployed, the parameters of the encoding process is adjusted dynamicallyfor both portions. It is important to note that regardless of theencoder selection and parameter adjustment, each portion is encodedindependently. While encoding the video portion, the encoding isperformed by assuming the full frame size (covering both guide and videoportions) and the guide portion of the full frame is padded with nulldata. This step, step 704, is performed at the HEE. At step 706, theencoded video and guide portion slices are sent to the LNE. If the LNEfunctionality is implemented as part of the HEE, then, the slices aredelivered to the LNE as packetized elementary stream format or anysimilar format as output of the video encoders. If LNE is implemented asa remote network equipment, the encoded slices are formatted in a formto be delivered over a network via a preferred method such as cablemodem protocol or any other preferred method. Once the slice-basedstreams are available in the LNE, the slice combiner at step 706 ordersthe slices in a form suitable for the decoding method at the receiverequipment. As depicted, in FIG. 7 (b), the guide portion and videoportion slices are ordered in a manner as if the original pictures inFIG. 7 (a) are scanned from left to right and top to bottom order. Eachof the slice packets are then assigned PIDs as discussed in FIG. 6 bythe multiplexer; PID1 is assigned to g1/s1 . . . g1/sn, PID2 to g2/s1 .. . g2/sn, . . . PID10 to g10/s1 . . . g10/sn, and PID11 is assigned tov/s1 . . . v/sn. The resultant transport stream containing theintra-coded slices of video and guide portions is illustrated in FIG. 7(c). Note that based on this transport stream structure, a receivingterminal as discussed in later parts of this description of theinvention, retrieves the original picture by constructing the videoframes row-by-row, first retrieving, assuming PID1 is desired, e.g.,g1/s1 of PID1 then v/s1 of PID11, next g1/s2 of PID1 then v/s2 of PID11and so on.

FIG. 8 illustrates a process 800 for producing a bitstream 808containing the slices from the predictive-coded pictures accompanyingthe transport stream generation process discussed in FIG. 7 forintra-coded slices. As shown in FIG. 6, illustratively, only thepredicted slices belonging to IPG page 1 is delivered. Following thesame arguments of encoding process in FIG. 7, at step 802, thepredictive-coded slices are generated at the HEE independently and thenforwarded to an LNE either as local or in a remote network location. Atstep 804, slices in the predictive-coded guide and video portion slices,illustratively from time periods t2 to t15, are scanned from left toright and top to bottom in slice-combiner and complete data is assignedPID 11 by the multiplexer. Note that the guide portion slices g1/s1 tog1/sn at each time period t2 to t15 does not change from theirintra-coded corresponding values at t1. Therefore, these slices arecoded as skipped macroblocks “sK”. Conventional encoder systems do notnecessarily skip macroblocks in a region even when there is no changefrom picture to picture. At step 806, the slice packets are ordered intoa portion of final transport stream, first including the video slicepackets v2/s1 v2/SN to v15/s1 v15/sN, then including the skipped guideslices sK/s1 sK/sN from t2 to t15 in the final transport stream. FIG. 9depicts a complete MPEG compliant transport stream 900 that contains thecomplete information needed by a decoder to recreate IPG pages that areencoded in accordance with the invention. The transport stream 900comprises the intra-coded bitstream 710 of the guide and video slices(PIDS1 to 11), a plurality of audio packets 902 identified by an audioPID, and the bitstream 806 containing the predictive-coded slices inPID11. The rate of audio packet insertion between video packets isdecided based on the audio and video sampling ratios. For example, ifaudio is digitally sampled as one tenth of video signal, then an audiopacket may be introduced into the transport stream every ten videopackets. The transport stream 900 may also contain, illustratively afterevery 64 packets, data packets that carry to the set top terminaloverlay updates, raw data, HTML, java, URL, instructions to load otherapplications, user interaction routines, and the like. The data PIDs areassigned to different set of data packets related to guide portion slicesets and also video portion slice sets.

FIG. 10 illustrates a process 1000, an alternative embodiment of process800 depicted in FIG. 8, for producing a predictive-coded slice bitstream1006. The process 1000, at step 1002, produces the slice base encodedpredictive-coded slices. At step 1004, the slices are scanned tointersperse the “skipped” slices (sk) with the video slices (v1). Theprevious embodiment scanned the skipped guide portion and video portionseparately. In this embodiment, each slice is scanned left to right andtop to bottom completely, including the skipped guide and video data. Assuch, at step 1008, the bitstream 1006 has the skipped guide and videoslices distributed uniformly throughout the transport stream.

The foregoing embodiments of the invention assumed that the IPG page wasdivided into one guide portion and one video portion. For example, inFIG. 1, the guide portion is the left half of the IPG page and the videoportion is the right half of the IPG page. However, the invention can beextended to have a guide portion and multiple video portions, e.g.,three. Each of the video portions may contain video having differentrates of motion, e.g., portion one may run at 30 frames per second,portions two and three may run at 2 frames per second. FIG. 11Aillustrates an exemplary embodiment of an IPG 1100 having a guideportion 1102 and three video portions 1104, 1106 and 1108. To encodesuch an IPG, each portion is separately encoded and assigned PIDs. FIG.11B illustrates an assignment map for encoding each portion of the IPGpage of FIG. 11A. The guide portion 1002 is encoded as slices g/s1through g/sN, while the first video portion 1004 is encoded as slicesv/s1 through v/sM, and the second video portion 1006 is encoded asslices j/sM+1 through j/sL, the third video portion 1008 is encoded asslices p/sL+1 through p/sN.

FIG. 12 depicts the scanning process 1200 used to produce a bitstream1210 containing the intra-coded slices. The scanning process 1200 flowsfrom left to right, top to bottom through the assigned slices of FIG.11B. PIDs are assigned, at step 1202, to slices 1 to M; at step 1204, toslices M+1 to L; and, at step 1206, to slices L+1 to N. As the encodedIPG is scanned, the PIDS are assigned to each of the slices. The guideportion slices are assigned PIDS 1 through 10, while the first videoportion slices are assigned PID11, the second video portion slices areassigned PID12 and the third video portion slices are assigned PID13.The resulting video portion of the bitstream 1210 contains the PIDS forslices 1−M, followed by PIDS for slices M+1 to L, and lastly by the PIDSfor L+1 to N.

FIG. 13 depicts a diagrammatical illustration of a process 1300 forassigning PIDS to the predictive-coded slices for the IPG of FIG. 11A.The scanning process 1300 is performed, at step 1302, from left toright, top to bottom through the V, J and P predicted encoded slices andPIDS are assigned where the V slices are assigned PID11, the J slicesare assigned PID 12 and the P slices are assigned PID13. After the videoportion predicted encoded slices have assigned PIDs, the process 1300,at step 1304, assigns PIDs to the skipped slices. The skipped guideslices vertically corresponding to the V slices are assigned PID11, theskipped slices vertically corresponding to the 3 slices are assignedPID12 and the skipped slices vertically corresponding to the P slicesare assigned PID13. At step 1308, the resulting predictive-codedbitstream 1312 comprises the predicted video slices in portion 1306 andthe skipped slices 1310. The bitstream 1210 of intra-coded slices andthe bitstream 1312 of predictive-coded slices are combined into atransport stream having a form similar to that depicted in FIG. 9.

To change pages in the guide, it is required to switch between programs(video PIDs for groups of slices) in a seamless manner. This cannot bedone cleanly using a standard channel change by the receiver switchingfrom PID to PID directly, because such an operation flushes the videoand audio buffers and typically gives half a second blank screen.

To have seamless decoder switching, a splice countdown (or random accessindicator) method is employed at the end of each video sequence toindicate the point at which the video should be switched from one PID toanother.

Using the same profile and constant bit rate coding for the video andgraphics encoding units, the generated streams for different IPG pagesare formed in a similar length compared to each other. This is due tothe fact that the source material is almost identical differing only inthe characters in the guide from one page to another. In this way, whilestreams are generated having nearly identical lengths, the streams arenot exactly the same length. For example, for any given sequence of 15video frames, the number of transport packets in the sequence variesfrom one guide page to another. Thus, a finer adjustment is required tosynchronize the beginnings and ends of each sequence across all guidepages in order for the countdown switching to work.

The invention provides the act of synchronization of a plurality ofstreams that provides seamless switching at the receiver.

Three methods are provided for that purpose:

First, for each sequence the multiplexer in the LNE identifies thelength of the longest guide page for that particular sequence, and thenadds sufficient null packets to the end of each other guide page so thatall the guide pages become the same length. Then, the multiplexer addsthe switching packets at the end of the sequence, after all the nullpackets.

The second method requires buffering of all the packets for all guidepages for each sequence. If this is allowed in the considered system,then the packets can be ordered in the transport stream such that thepackets for each guide page appear at slightly higher or lowerfrequencies, so that they all finish at the same point. Then, theswitching packets are added by the multiplexer in the LNE at the end ofeach stream without the null padding.

A third method is to start each sequence together, and then wait untilall the packets for all the guide pages have been generated. Once thegeneration of all packets is completed, switching packets are placed inthe streams at the same time and point in each stream.

Depending on the implementation of decoder units within the receiver andrequirements of the considered application, each one of the methods canbe applied with advantages. For example, the first method, which isnull-padding, can be applied to avoid bursts of N packets of the samePID into a decoder's video buffer faster than the MPEG specified rate(e.g., 1.5 Mbit).

The teachings of the above three methods can be extended apply tosimilar synchronization problems and to derive similar methods forensuring synchronization during stream switching.

E. Receiver 224

FIG. 14 depicts a block diagram of the receiver 224 (also known as a settop terminal (STT) or user terminal) suitable for use in producing adisplay of an IPG in accordance with the present invention. The STT 224comprises a tuner 1410, a demodulator 1420, a transport demultiplexer1430, an audio decoder 1440, a video decoder 1450, an on-screen displayprocessor (OSD) 1460, a frame store memory 1462, a video compositor 1490and a controller 1470. US er interaction is provided via a remotecontrol unit 1480. Tuner 1410 receives, e.g., a radio frequency (RF)signal comprising, for example, a plurality of quadrature amplitudemodulated (QAM) information signals from a downstream (forward) channel.Tuner 1410, in response to a control signal TUNE, tunes a particular oneof the QAM information signals to produce an intermediate frequency (IF)information signal. Demodulator 1420 receives and demodulates theintermediate frequency QAM information signal to produce an informationstream, illustratively an MPEG transport stream. The MPEG transportstream is coupled to a transport stream demultiplexer 1430.

Transport stream demultiplexer 1430, in response to a control signal TDproduced by controller 1470, demultiplexes (i.e., extracts) an audioinformation stream A and a video information stream V. The audioinformation stream A is coupled to audio decoder 1440, which decodes theaudio information stream and presents the decoded audio informationstream to an audio processor (not shown) for subsequent presentation.The video stream V is coupled to the video decoder 1450, which decodesthe compressed video stream V to produce an uncompressed video stream VDthat is coupled to the video compositor 1490. OSD 1460, in response to acontrol signal OSD produced by controller 1470, produces a graphicaloverlay signal VOSD that is coupled to the video compositor 1490. Duringtransitions between streams representing the user interfaces, buffers inthe decoder are not reset. As such, the user interfaces seamlesslytransition from one screen to another.

The video compositor 1490 merges the graphical overlay signal VOSD andthe uncompressed video stream VD to produce a modified video stream(i.e., the underlying video images with the graphical overlay) that iscoupled to the frame store unit 1462. The frame store unit 1462 storesthe modified video stream on a frame-by-frame basis according to theframe rate of the video stream. Frame store unit 1462 provides thestored video frames to a video processor (not shown) for subsequentprocessing and presentation on a display device.

Controller 1470 comprises a microprocessor 1472, an input/output module1474, a memory 1476, an infrared (IR) receiver 1475 and supportcircuitry 1478. The microprocessor 1472 cooperates with conventionalsupport circuitry 1478 such as power supplies, clock circuits, cachememory and the like as well as circuits that assist in executing thesoftware routines that are stored in memory 1476. The controller 1470also contains input/output circuitry 1474 that forms an interfacebetween the controller 1470 and the tuner 1410, the transportdemultiplexer 1430, the onscreen display unit 1460, the back channelmodulator 1495, and the remote control unit 1480. Although thecontroller 1470 is depicted as a general purpose computer that isprogrammed to perform specific interactive program guide controlfunction in accordance with the present invention, the invention can beimplemented in hardware as an application specific integrated circuit(ASIC). As such, the process steps described herein are intended to bebroadly interpreted as being equivalently performed by software,hardware, or a combination thereof.

In the exemplary embodiment of FIG. 14, the remote control unit 1480comprises an 8-position joy stick, a numeric pad, a “select” key, a“freeze” key and a “return” key. User manipulations of the joy stick orkeys of the remote control device are transmitted to a controller via aninfra red (IR) link. The controller 1470 is responsive to such usermanipulations and executes related user interaction routines 1400, usesparticular overlays that are available in an overlay storage 1479.

After the signal is tuned and demodulated, the video streams arerecombined via stream processing routine 1402 to form the videosequences that were originally compressed. The processing unit 1402employs a variety of methods to recombine the slice-based streams,including, using PID filter 1404, demultiplexer 1430, as discussed inthe next sections of this disclosure of the invention. Note that the PIDfilter implemented illustratively as part of the demodulator is utilizedto filter the undesired PIDs and retrieve the desired PIDs from thetransport stream. The packets to be extracted and decoded to form aparticular IPG are identified by a PID mapping table (PMT) 1477. Afterthe stream processing unit 1402 has processed the streams into thecorrect order (assuming the correct order was not produced in the LNE),the slices are sent to the MPEG decoder 1450 to generate the originaluncompressed IPG pages. If an exemplary transport stream with two PIDsas discussed in previous parts of the this disclosure, excluding dataand audio streams, is received, then the purpose of the streamprocessing unit 1402 is to recombine the intra-coded slices with theircorresponding predictive-coded slices in the correct order before therecombined streams are coupled to the video decoder. This completeprocess is implemented as software or hardware. In the illustrated IPGpage slice structure, only one slice is assigned per row and each row isdivided into two portions, therefore, each slice is divided into guideportion and video portion. In order for the receiving terminal toreconstruct the original video frames, one method is to construct afirst row from its two slices in the correct order by retrieving twocorresponding slices from the transport stream, then construct a secondrow from its two slices, and so on. For this purpose, a receiver isrequired to process two PIDs in a time period. The PID filter can beprogrammed to pass two desired PIDs and filter out the undesired PIDs.The desired PIDs are identified by the controller 1470 after the userselects an IPG page to review. A PID mapping table (1477 of FIG. 14) isaccessed by the controller 1470 to identify which PIDS are associatedwith the desired IPG. If a PID filter is available in the receiverterminal, then it is utilized to receive two PIDs containing slices forguide and video portions. The demultiplexer then extracts packets fromthese two PIDs and couples the packets to the video decoder in the orderin which they arrived. If the receiver does not have an optional PIDfilter, then the demultiplexer performs the two PID filtering andextracting functions. Depending on the preferred receiverimplementation, the following methods are provided in FIGS. 15-18 torecombine and decode slice-based streams.

E1. Recombination Method 1

In this first method, intra-coded slice-based streams (I-streams) andthe predictive-coded slice-based streams (PRED streams) to be recombinedkeep their separate PIDs until the point where they must bedepacketized. The recombination process is conducted within thedemultiplexer 1430 of the subscriber equipment For illustrativepurposes, assuming a multi-program transport stream with each programconsisting of I-PIDs for each intra-coded guide slice, I-PIDs for theintra-coded video slices, one PRED-PID for predicted guide and video, anaudio-PID, and multiple data-PIDs, any packet with a PID that matchesany of the PIDs within the desired program (as identified in a programmapping table) are depacketized and the payload is sent to theelementary stream video decoder. Payloads are sent to the decoder inexactly in the order in which the packets arrive at the demultiplexer.

FIG. 15 is a flow diagram of the first packet extraction method 1500.The method starts at step 1505 and proceeds to step 1510 to wait for(user) selection of an I-PID to be received. The I-PID, as the firstpicture of a stream's GOP, represents the stream to be received.However, since the slice-based encoding technique assigns two or moreI-PIDS to the stream (i.e., I-PIDs for the guide portion and for one ormore video portions), the method must identify two or more I-PIDs. Upondetecting a transport packet having the selected I-PIDs, the method 1500proceeds to step 1515.

At step 1515, the I-PID packets (e.g., packets having PID-1 and PID-11)are extracted from the transport stream, including the headerinformation and data, until the next picture start code. The headerinformation within the first-received I-PID access unit includessequence header, sequence extension, group start code, GOP header,picture header, and picture extension, which are known to a reader thatis skilled in MPEG-1 and MPEG-2 compression standards. The headerinformation in the next I-PID access units that belongs to the secondand later GOP's includes group start code, picture start code, pictureheader, and extension. The method 1500 then proceeds to step 1520 wherethe payloads of the packets that includes header information related tovideo stream and I-picture data are coupled to the video decoder 1550 asvideo information stream V. The method 1500 then proceeds to step 1525.

At step 1525, the predicted picture slice-based stream packets PRED-PID,illustratively the PID-11 packets of fourteen predicted pictures in aGOP of size fifteen, are extracted from the transport stream. At step1530, the payloads of the packets that includes header informationrelated to video stream and predicted-picture data are coupled to thevideo decoder 1550 as video information stream V. At the end of step1530, a complete GOP, including the I-picture and the predicted-pictureslices, are available to the video decoder 1550. As the payloads aresent to the decoder in exactly in the order in which the packets arriveat the demultiplexer, the video decoder decodes the recombined streamwith no additional recombination process. The method 1500 then proceedsto step 1535.

At step 1535, a query is made as to whether a different I-PID isrequested, e.g., new IPG is selected. If the query at step 1535 isanswered negatively, then the method 1500 proceeds to step 1510 wherethe transport demultiplexer 1530 waits for the next packets having thePID of the desired I-picture slices. If the query at step 1535 isanswered affirmatively, then the PID of the new desired I-picture slicesis identified at step 1540 and the method 1500 returns to step 1510.

The method 1500 of FIG. 15 is used to produce a conformant MPEG videostream V by concatenating a desired I-picture slices and a plurality ofP- and/or B-picture slices forming a pre-defined GOP structure.

E2. Recombination Method 2

The second method of recombining the video stream involves themodification of the transport stream using a PID filter. A PID filter1404 can be implemented as part of the demodulator 1420 of FIG. 14 or aspart of demultiplexer.

For illustrative purposes, assuming a multi-program transport streamwith each program consisting of an I-PIDs for both video and guide,PRED-PID for both video and guide, audio-PID, and data-PID, any packetwith a PID that matches any of the PIDs within the desired program asidentified by the program mapping table to be received have its PIDmodified to the lowest video PID in the program (the PID which isreferenced first in the program's program mapping table (PMT)). Forexample, in a program, assuming that a guide slice I-PID is 50, thevideo slice I-PID is 51 and PRED-PID is 52. Then, the PID-filtermodifies the video I-PID and the PRED-PID as 50 and thereby, I- andPredicted-Picture slice access units attain the same PID number andbecome a portion of a common stream.

As a result, the transport stream output from the PID filter contains aprogram with a single video stream, whose packets appear in the properorder to be decoded as valid MPEG bitstream.

Note that the incoming bit stream does not necessarily contain anypackets with a PID equal to the lowest video PID referenced in theprograms PMT. Also note that it is possible to modify the video PIDs toother PID numbers than lowest PID without changing the operation of thealgorithm.

When the PIDs of incoming packets are modified to match the Pad's ofother packets in the transport stream, the continuity counters of themerged Pad's may become invalid at the merge points, due to each PIDhaving its own continuity counter. For this reason, the discontinuityindicator in the adaptation field is set for any packets that mayimmediately follow a merge point. Any decoder components that check thecontinuity counter for continuity is required to correctly process thediscontinuity indicator bit.

FIG. 16 illustrates the details of this method, in which, it starts atstep 1605 and proceeds to step 1610 to wait for (user) selection of twoI-PIDs, illustratively two PIDs corresponding to guide and video portionslices, to be received. The I-PIDs, comprising the first picture of astream's GOP, represents the two streams to be received. Upon detectinga transport packet having one of the selected I-PIDs, the method 1600proceeds to step 1615.

At step 1615, the PID number of the I-stream is re-mapped to apredetermined number, PID*. At this step, the PID filter modifies allthe Pad's of the desired I-stream packets to PID*. The method thenproceeds to step 1620, wherein the PID number of the predicted pictureslice streams, PRED-PID, is re-mapped to PID*. At this step, the PIDfilter modifies all the Pad's of the PRED-PID packets to PID*. Themethod 1600 then proceeds to step 1625.

At step 1625, the packets of the PID* stream are extracted from thetransport stream by the demultiplexer. The method 1600 then proceeds tostep 1630, where the payloads of the packets that includes video streamheader information and I-picture and predicted picture slices arecoupled to the video decoder as video information stream V. Note thatthe slice packets are ordered in the transport stream in the same orderas they are to be decoded, i.e., a guide slice packets of first rowfollowed by video slice packets of first row, second row, and so on. Themethod 1600 then proceeds to 1635.

At step 1635, a query is made as to whether a different set of (two)I-PIDs are requested. If the query at step 1635 is answered negatively,then the method 1600 proceeds to step 1610 where the transportdemultiplexer waits for the next packets having the identified I-PIDs.If the query at step 1635 is answered affirmatively, then the two PIDsof the new desired I-picture is identified at step 1640 and the method1600 returns to step 1610.

The method 1600 of FIG. 16 is used to produce a conformant MPEG videostream by merging the intra-coded slice streams and predictive-codedslice streams before the demultiplexing process.

E3. Recombination Method 3

The third method accomplishes MPEG bitstream recombination by usingsplicing information in the adaptation field of the transport packetheaders by switching between video PIDs based on splice countdownconcept.

In this method, the MPEG streams signal the PID to PID switch pointsusing the splice countdown field in the transport packet header'sadaptation field. When the PLO filter is programmed to receive one ofthe PIDs in a program's PMT, the reception of a packet containing asplice countdown value of 0 in its header's adaptation field causesimmediate reprogramming of the PID filter to receive the other videoPID. Note that a special attention to splicing syntax is required insystems where splicing is used also for other purposes.

FIG. 17 illustrates the details of this method, in which, it starts atstep 1705 and proceeds to step 1710 to wait for (user) selection of twoI-PIDs to be received. The I-PIDs, comprising the first picture of astream's GOP, represents the stream to be received. Upon detecting atransport packet having one of the selected I-PIDs, the method 1700proceeds to step 1715.

At step 1715, the I-PID packets are extracted from the transport streamuntil, and including, the 1-PID packet with slice countdown value ofzero. The method 1700 then proceeds to step 1720 where the payloads ofthe packets that includes header information related to video stream andI-picture slice data are coupled to the video decoder as videoinformation stream V. The method 1700 then proceeds to step 1725.

At step 1725, the PID filter is re-programmed to receive the predictedpicture packets PRED-PID. The method 1700 then proceeds to 1730. At step1730, the predicted stream packets, illustratively the PID11 packets ofpredicted picture slices, are extracted from the transport stream. Atstep 1735, the payloads of the packets that includes header informationrelated to video stream and predicted-picture data are coupled to thevideo decoder. At the end of step 1735, a complete GOP, including theI-picture slices and the predicted-picture slices, are available to thevideo decoder. As the payloads are sent to the decoder in exactly in theorder in which the packets arrive at the demultiplexer, the videodecoder decodes the recombined stream with no additional recombinationprocess. The method 1700 then proceeds to step 1740.

At step 1740, a query is made as to whether a different I-PID set (two)is requested. If the query at step 1740 is answered negatively, then themethod 1700 proceeds to step 1750 where the PID filter is re-programmedto receive the previous desired I-PIDs. If answered affirmatively, thenthe PIDs of the new desired I-picture is identified at step 1745 and themethod proceeds to step 1750, where the PID filter is re-programmed toreceive the new desired I-PIDs. The method then proceeds to step 1745,where the transport demultiplexer waits for the next packets having thePIDs of the desired I-picture.

The method 1700 of FIG. 17 is used to produce a conformant MPEG videostream, where the PID to PID switch is performed based on a splicecountdown concept. Note that the slice recombination can also beperformed by using the second method where the demultiplexer handles thereceiving PIDs and extraction of the packets from the transport streambased on the splice countdown concept. In this case, the same process isapplied as FIG. 17 with the difference that instead of reprogramming thePID filter after “0” splice countdown packet, the demultiplexer isprogrammed to depacketize the desired PIDs.

E4. Recombination Method 4

For the receiving systems that do not include a PID filter and for thosereceiving systems in which the demultiplexer can not process two PIDsfor splicing the streams, a fourth method presented herein provides thestream recombination. In a receiver that cannot process two PIDs, two ormore streams with different PIDs are spliced together via an additionalsplicing software or hardware and can be implemented as part of thedemultiplexer. The process is described below with respect to FIG. 18.The algorithm provides the information to the demultiplexer about whichPID to be spliced to as the next step. The demultiplexer processes onlyone PID but a different PID after the splice occurs.

FIG. 18 depicts a flow diagram of this fourth process 1800 forrecombining the IPG streams. The process 1800 begins at step 1801 andproceeds to step 1802 wherein the process defines an array of elementshaving a size that is equal to the number of expected PIDs to bespliced. It is possible to distribute splice information in a picture asdesired according to slice structure of the picture and the desiredprocessing form at the receiver. For example, in the slice based streamsdiscussed in this invention, for an I picture, splice information may beinserted into slice row portions of guide and video data. At step 1804,the process initializes the video PID hardware with for each entry inthe array. At step 1810, the hardware splice process is enabled and thepackets are extracted by the demultiplexer. The packet extraction mayalso be performed at another step within the demultiplexer. At step1812, the process checks a hardware register to determine if a splicehas been completed. If the splice has occurred, the process, at step1814, disables the splice hardware and, at step 1816, sets the video PIDhardware to the next entry in the array. The process then returns alongpath 1818 to step 1810. If the splice has not occurred, the processproceeds to step 1820 wherein the process waits for a period of time andthen returns along path 1822 to step 1812.

In this manner, the slices are spliced together by the hardware withinthe receiver. To facilitate recombining the slices, the receiver is sentan array of valid PID values for recombining the slices through a userdata in the transport stream or another communications link to the STTfrom the HEE. The array is updated dynamically to ensure that thecorrect portions of the IPG are presented to the user correctly. Sincethe splice points in slice based streams may occur at a frequent level,a software application may not have the capability to control thehardware for splicing operation as discussed above. If this is the case,then, firmware is dedicated to control the demodulator hardware forsplicing process at a higher rate than a software application canhandle.

F. Example Interactive Program Guide

The video streams representing the IPG may be carried in a singletransport stream or multiple transport streams, within the form of asingle or multi-programs as discussed below with respect to thedescription of the encoding system. A user desiring to view the next 1.5hour time interval (e.g., 9:30-11:00) may activate a “scroll right”object (or move the joystick to the right when a program within programgrid occupies the final displayed time interval). Such activationresults in the controller of the STT noting that a new time interval isdesired. The video stream corresponding to the new time interval is thendecoded and displayed. If the corresponding video stream is within thesame transport stream (i.e., a new PID), then the stream is immediatelydecoded and presented. If the corresponding video stream is within adifferent transport stream, then the related transport stream isextracted from the broadcast stream and the related video stream isdecoded and presented. If the corresponding transport stream is within adifferent broadcast stream, then the related broadcast stream is tuned,the corresponding transport stream is extracted, and the desired videostream is decoded and presented.

It is important to note that each extracted video stream is associatedwith a common audio stream. Thus, the video/audio barker function of theprogram guide is continuously provided, regardless of the selected videostream. Also note that the teachings of the invention is equallyapplicable to systems and user interfaces that employs multiple audiostreams.

Similarly, a user interaction resulting in a prior time interval or adifferent set of channels results in the retrieval and presentation of arelated video stream. If the related video stream is not part of thebroadcast video streams, then a pointcast session is initiated. For thispurpose, the STT sends a request to the head end via the back channelrequesting a particular stream. The head end then processes the request,retrieves the related guide and video streams from the informationserver, incorporates the streams within a transport stream as discussedabove (preferably, the transport stream currently being tuned/selectedby the STT) and informs the STT which PIDs should be received, and fromwhich transport stream should be demultiplexed. The STT then extractsthe related PIDs for the IPG. In the case of the PID being within adifferent transport stream, the STT first demultiplexes thecorresponding transport stream (possibly tuning a different QAM streamwithin the forward channel).

Upon completion of the viewing of the desired stream, the STT indicatesto the head end that it no longer needs the stream, whereupon the headend tears down the pointcast session. The viewer is then returned to thebroadcast stream from which the pointcast session was launched.

Although various embodiments which incorporate the teachings of thepresent invention have been shown and described in detail herein, thoseskilled in the art can readily devise many other varied embodiments thatstill incorporate these teachings. An important note is that the methodand apparatus described herein is applicable to any number of sliceassignments to a video frame and any type of slice structures. Thepresented algorithms are also applicable to any number of PIDassignments to intra-coded and predictive-coded slice based streams. Forexample, multiple PIDs can be assigned to the predictive-coded sliceswithout loss of generality. Also note that the method and apparatusdescribed herein is fully applicable picture based encoding by assigningeach picture only to a one slice, where each picture is encoded then asa full frame instead of multiple slices.

G. Multi-Functional User Interface with Picture-in-Picture Functionality

One aspect of the present invention relates to providingpicture-in-picture (PIP) functionality using slice-based encoding. ThePIP functionality supplies multiple (instead of singular) video content.The present invention also relates to providing an additional userinterface (UI) layer on top (presented to the viewer as an initialscreen) of the interactive program guide (IPG). The additional UI layerextends the functionality of the IPG from a programming guide to amulti-functional user interface. The multi-functional user interface maybe used to provide portal functionality to such applications aselectronic commerce, advertisement, video-on-demand, and otherapplications.

A matrix representation of IPG data with single video content isdescribed above in relation to FIG. 6. As shown in FIG. 6, single videocontent, including time-sequenced video frames V1 to V15, is sharedamong multiple guide pages g1 to g10. A diagrammatic flow of aslice-based process for generating a portion of the transport streamcontaining intra-coded video and graphics slices is described above inrelation to FIG. 7. As described below, slice-based encoding may also beused to provide picture-in-picture (PIP) functionality and amulti-functional user interface.

FIG. 19 is a schematic diagram illustrating slice-based formation of anintra-coded portion of a stream of packets 1900 including multipleintra-coded guide pages and multiple intra-coded video frames inaccordance with an embodiment of this invention. The intra-coded videoframes generally occur at a first frame of a group of pictures (GOP).Hence, the schematic diagram in FIG. 19 is denoted as corresponding totime t1.

In the example illustrated in FIG. 19, packet identifiers (PIDs) 1through 10 are assigned to ten program guide pages (g1 through g10), andPIDs 11 through 13 are assigned to three video streams (V1, M1, and K1).Each guide page is divided into N slices S1 to SN, each slice extendingfrom left to right of a row. Likewise, each intra-coded video frame isdivided into N slices s1 to sN.

As shown in FIG. 19, one way to form a stream of packets is to scanguide and video portion slices serially. In other words, packets fromthe first slice (s1) are included first, then packets from the secondslice (s2) are included second, then packets from the third slice (s3)are included third, and so on until packets from the Nth slice (sN) areincluded last, where within each slice grouping, packets from the guidegraphics are included in serial order (g1 to g10), then packets from theintra-coded video slices are included in order (V1, M1, K1). Hence, thestream of packets are included in the order illustrated in FIG. 19.

FIG. 20 is a schematic diagram illustrating slice-based formation ofpredictive-coded portion of multiple video stream packets in accordancewith an embodiment of this invention. The predictive-coded video frames(either predicted P or bidirectional B frames in MPEG2) generally occurafter the first frame of a group of pictures (GOP). For FIG. 20, it isassumed that the GOP has 15 frames. Hence, the schematic diagram in FIG.20 is denoted as corresponding to times t2 to t15.

In the example illustrated in FIG. 20, PIDs 11 through 13 are assignedto three video streams (V1, M1, and K1), each predictive-coded videoframe of each video stream being divided into N slices s1 to sN.

As shown in FIG. 20, one way to form a stream of packets is to scanserially from the time t2 through tN. In other words, packets 2002 fromthe second time (t2) are included first, then packets 2003 from thethird time (t3) are included second, then packets 2004 from the fourthtime (t4) are included third, and so on until packets 2015 from thefifteenth time (t15) are included last. Within each time, packets ofpredictive-coded video frames from each video stream are groupedtogether by slice (S1 through S15). Within each slice grouping, thepackets are ordered with the packet corresponding to the slice for videostream V as first, the packet corresponding to the slice for videostream M as second, and the packet corresponding to the slice for videostream K as third. Hence, the stream of packets are included in theorder illustrated in FIG. 20.

FIG. 21 is a schematic diagram illustrating slice-based formation of astream of packets including skipped guide pages in accordance with anembodiment of this invention. The formation of the stream of packets inFIG. 21 is similar to the formation of the stream of packets in FIG. 20.However, the skipped guide page content (SK) is the same for each sliceand for each video stream. In contrast, the predictive-coded videoframes are different for each slice and for each video stream.

In accordance with an embodiment of the present invention, for each timet2 through t15, the packets containing the skipped guide pages followthe corresponding packets containing the predictive-coded video frames.For example, for time t2, the first row of skipped guide packets 2102follow the first row of predictive-coded packets 2002. For time t3, thesecond row of skipped guide packets 2103 follow the second row ofpredictive-coded packets 2003. And so on.

FIG. 22 is a block diagram illustrating a system and apparatus formultiplexing various packet streams to generate a transport stream inaccordance with an embodiment of this invention. The apparatus shown inFIG. 22 may be employed as part of the local neighborhood equipment(LNE) 228 of the distribution system described above in relation to FIG.2. In the example illustrated in FIG. 22, the various packet streamsinclude three packetized audio streams 2202, 2204, and 2206, and thevideo and graphic packet stream 2214 comprising the intra-coded 1900,predictive-coded 2000, and skipped-coded 2100 packets.

The three packetized audio streams 2202, 2204, and 2206 are input into amultiplexer 2208. The multiplexer 2208 combines the three streams into asingle audio packet stream 2210. The single audio stream 2210 is theninput into a remultiplexer 2212. An alternate embodiment of the presentinvention may input the three streams 2202, 2204, and 2206 directly intothe remultiplexer 2212, instead of first creating the single audiostream 2210.

The video and graphic packet stream 2214 is also input into theremultiplexer 2212. As described above in relation to FIGS. 19-21, thevideo and graphic packet stream 2214 comprises the intra-coded 1900,predictive-coded 2000, and skipped-coded 2100 packets. One way to orderthe packets for a single GOP is illustrated in FIG. 22. First, thepackets 1900 with PID 1 to PID 13 for intra-coded guide and video attime t1 are transmitted. Second, packets 2002 with PID 11 to PID 13 forpredictive-coded video at time t2 are transmitted, followed by packets2102 with PID 11 to PID 13 for skipped-coded guide at time t2. Third,packets 2003 with PID 11 to PID 13 for predictive-coded video at time t3are transmitted, followed by packets 2103 with PID 11 to PID 13 forskipped-coded guide at time t3. And so on, until lastly for the GOP,packets 2015 with PID 11 to PID 13 for predictive-coded video at timet15 are transmitted, followed by packets 2115 with PID 11 to PID 13 forskipped-coded guide at time t15.

The remultiplexer 2212 combines the video and graphic packet stream 2214with the audio packet stream 2210 to generate a transport stream 2216.In one embodiment, the transport stream 2216 interleaves the audiopackets with video and graphics packets. In particular, the interleavingmay be done such that the audio packets for time t1 are next to thevideo and graphics packets for time t1, the audio packets for time t2are next to the video and graphics packets for time t2, and so on.

FIG. 23 is a schematic diagram illustrating slice-based partitioning ofmultiple objects of an exemplary user interface that is presented to theuser as an initial screen in accordance with an embodiment of thisinvention. In the example illustrated in FIG. 23, nine objects O1through O9 are shown. As illustrated in part (a) on the left side ofFIG. 23, these nine objects may be displayed on one full-size videoscreen by dividing the screen into a 3×3 matrix with nine areas. In thiscase, each of the nine objects would be displayed at ⅓ of the fullhorizontal resolution and ⅓ of the full vertical resolution.

Part (b) on the right side of FIG. 23 shows one way for slice-basedpartitioning of the nine objects being displayed in the 3×3 matrix. Theframe in FIG. 23( b) is divided into 3N horizontal slices. Slices 1 to Ninclude objects O1, O2, and O3, dividing each object into N horizontalslices. Slices N+1 to 2N include objects O4, O5, and O6, dividing eachobject into N horizontal slices. Lastly, slices 2N+1 to 3N includeobjects O7, O8, and O9, dividing each object into N horizontal slices.

FIG. 24 is a block diagram illustrating a cascade compositor forresizing and combining multiple video inputs to create a single videooutput which may be encoded into a video object stream in accordancewith an embodiment of this invention. In the example shown in FIG. 24,the number of multiple video inputs is nine. In this case, each videoinput corresponds to a video object from the arrangement shown in FIG.23( a).

The first compositor 2402 receives a first set of three full-size videoinputs which correspond to the first row of video objects O1, O2, and O3in FIG. 23( a). The first compositor 2402 resizes each video input byone third in each dimension, then arranges the resized video inputs toform the first row of video objects. The first compositor 2402 outputs afirst composite video signal 2403 which includes the first row of videoobjects.

The second compositor 2404 receives the first composite video signal2403 from the first compositor 2402. The second compositor 2404 alsoreceives a second set of three full-size video inputs which correspondsto the second row of video objects O4, O5, and O6 in FIG. 23( a). Thesecond compositor resizes and arranges these three video inputs. It thenadds them to the first composite video signal 2403 to form a secondcomposite video signal 2405 which includes the first and second rows ofobjects.

The third compositor 2406 receives the second composite video signal2405 and a third set of three full-size video inputs which correspondsto the third row of video objects O7, O8, and O9 in FIG. 23( a). Thethird compositor 2406 resizes and arranges these three video inputs. Itthen adds them to the second composite video signal 2405 to form a thirdcomposite video signal 2407 which includes all three rows of objects.

An encoder 2408 receives the third composite video signal 2407 anddigitally encodes it to form a video object stream 2409. The encodingmay be slice-based encoding using the partitioning shown in FIG. 23( b).

FIG. 25 is a block diagram illustrating a system and apparatus formultiplexing video object and audio streams to generate a transportstream in accordance with an embodiment of this invention. The apparatusshown in FIG. 25 may be employed as part of the local neighborhoodequipment (LNE) 228 of the distribution system described above inrelation to FIG. 2. In the example illustrated in FIG. 25, the variouspacket streams include a video object stream 2502 and a multiplexedpacketized audio stream 2504.

The multiplexed packetized audio stream 2504 includes multiple audiostreams which are multiplexed together. Each audio stream may belong toa corresponding video object. The multiplexed packetized audio stream2504 is input into a remultiplexer (remux) 2506.

The video object stream 2502 is also input into the remultiplexer 2506.The encoding of the video object stream 2502 may be slice-based encodingusing the partitioning shown in FIG. 23( b). In this case, each objectis assigned a corresponding packet identifier (PID). For example, thefirst object O1 is assigned PID 101, the second object O2 is assignedPID 102, the third object O3 is assigned PID 103, and so on, and theninth object O9 is assigned PID 109.

The remultiplexer 2506 combines the video object stream 2502 with themultiplexed packetized audio stream 2504 to generate an object transportstream 2508. In one embodiment, the object transport stream 2508interleaves the audio packets with video object packets. In particular,the interleaving may be done such that the audio packets for time t1 arenext to the video object packets for time t1, the audio packets for timet2 are next to the video object packets for time 12, and so on.

FIG. 26 is a block diagram illustrating a system and apparatus fordemultiplexing a transport stream to regenerate video object and audiostreams for subsequent decoding in accordance with an embodiment of thisinvention. The system and apparatus includes a demultiplexer 2602 and avideo decoder 2604.

The demultiplexer 2602 receives the object transport stream 2508 anddemultiplexes the stream 2508 to separate out the video object stream2502 and the multiplexed packetized audio stream 2504. The video objectstream 2502 is further processed by the video decoder 2604. For example,as illustrated in FIG. 26, the video decoder 2604 may output a videoobject page 2606 which displays reduced-size versions of the nine videoobjects O1 through O9.

FIG. 27 is a schematic diagram illustrating interaction with objects byselecting them to activate a program guide, an electronic commercewindow, a video on-demand window, or an advertisement video inaccordance with an embodiment of this invention. In the exampleillustrated in FIG. 27, a video display 2702 may display variousobjects, including multiple video channel objects (Channels A through F,for example), an advertisement object, a video on-demand (VOD) object,and an electronic commerce (e-commerce) object.

Each of the displayed objects may be selected by a user interacting witha set-top terminal. For example, if the user selects the channel Aobject, then the display may change to show a relevant interactiveprogram guide (IPG) page 2704. The relevant IPG page 2704 may include,for example, a reduced-size version of the current broadcast on channelA and guide data with upcoming programming for channel A or the guidepage where channel A is located. The audio may also change to the audiostream corresponding to channel A.

As another example, if the user selects the advertisement object, thenthe display may change to show a related advertisement video (ad video)2706. Further, this advertisement video may be selected, leading to anelectronic commerce page relating to the advertisement. The audio mayalso change to an audio stream corresponding to the advertisement video.

As yet another example, if the user selects the VOD object, then thedisplay may change to show a VOD window 2708 which enables andfacilitates selection of VOD content by the user. Further, once the userselects a particular video for on-demand display, an electronic commercepage may be displayed to make the transaction between the user and theVOD provider.

As yet another example, if the user selects the electronic commerce(e-commerce) object, then the display may change to show an e-commercewindow 2710 which enables and facilitates electronic commerce. Forexample, the e-commerce window 2710 may comprise a hypertext markuplanguage (HTML) page including various multimedia content andhyperlinks. The hyperlinks may, for example, link to content on theworld wide web, or link to additional HTML pages which provides furtherproduct information or opportunities to make transactions.

FIG. 28 is a schematic diagram illustrating interacting with an objectby selecting it to activate a full-resolution broadcast channel inaccordance with an embodiment of this invention. In this example, if theuser selects the object for channel E, the display changes to afull-resolution display 2802 of the video broadcast for channel E, andthe audio changes to the corresponding audio stream. The same principleapplies when the channel is pointcast to a specific viewer.

FIG. 29 is an exemplary flow chart illustrating an object selectionoperation in accordance with an embodiment of this invention. While inthe receiving operation, the PID filter is employed as an example tofulfill the PID selection operation, any of the preferred filtering anddemultiplexing methods discussed in FIGS. 15, 16, 17, and 18 can beutilized. The exemplary operation includes the following steps:

In a first step 2902, the video decoder 2604 (decodes and) outputs thevideo object page 2606 which includes the nine objects O1 through O9. Ina second step 2904, a user selects an object via a set top terminal orremote control. For example, the object may be the first object O1 whichmay correspond to channel A. In this example, selection of the firstobject O1 results in the display on a corresponding IPG page 2704including guide data and a reduced-size version of the channel Abroadcast.

In a third step 2906, a PID filter is reprogrammed to receive packetsfor O1 and associated guide data. For example, if packets for videoobject O1 are identified by PID 101, and packets for the associatedguide data are identified by PID 1, then the HD filter would bereprogrammed to receive packets with PID 101 and PID 1. This filteringstep 2906 is described further below in relation to FIG. 30. Suchreprogramming of the HD filter would occur only if such a PID filter.One system and method using such a PID filter is described above inrelation to FIG. 17. The methods in FIG. 15, 16, or 18 can be employeddepending on the receiving terminal capabilities and requirements.

In a fourth step 2908, a demultiplexer (Demux) depacketizes slices ofthe first object O1 and associated guide data. Note that this step 2908and the previous step 2906 are combined in some of the related methodsof FIGS. 15, 16, and 18. Subsequently, in a fifth step 2910, a slicerecombiner reconstitutes the IPG page including the reduced-size versionof the channel A broadcast and the associated guide data. Slices wouldonly be present if the first object O1 and associated guide data wereencoded using a slice-based partitioning technique, such as the onedescribed above in relation to FIG. 23( b).

Finally, in a sixth step 2912, a video decoder decodes and outputs theIPG page for viewing by the user.

FIG. 30 is a schematic diagram illustrating PID filtering prior to slicerecombination in accordance with an embodiment of this invention. FIG.30 shows an example of a transport stream 3002 received by a set topterminal. The transport stream 3002 includes intra-coded guide packets3004, predictive-coded (skipped) guide packets 3006, and intra-coded andpredictive-coded video object packets 3008.

In the example illustrated in FIG. 30, the intra-coded guide packets3004 include slice-partitioned guide graphics data for the first frameof each group of pictures (GOP) for each of ten IPG pages. Theseintra-coded packets 3004 may, for example, be identified by PID 1through PID 10 as described above in relation to FIG. 19.

Similarly, the skipped-coded guide packets 3006 include skipped-codeddata for the second through last frames of each GOP for each of ten IPGpages. These skipped-coded packets 3006 may be identified, for example,by PID 11 as described above in relation to FIG. 21.

In the example illustrated in FIG. 30, the intra-coded andpredictive-coded video object packets 3008 include slice-partitionedvideo data for each of nine objects O1 through O9. These packets 3008may, for example, be identified by PID 101 through PID 109 as describedabove in relation to FIG. 25.

The transport stream 3002 is filtered 3010 by a PID filter. Thefiltering process 3010 results in received packets 3012. For example, ifthe PID filter is programmed to receive only packets corresponding tothe first object O1 (PID 101) and associated guide data (PIDs 1 and 11),then the received packets 3012 would include only those packets withPIDs 101, 1, and 11.

FIG. 31 is a schematic diagram illustrating slice recombination inaccordance with an embodiment of this invention. In this embodiment,slice recombination occurs after PID filtering. A slice recombinerreceives the PID-filtered packets 3012 and performs the slicerecombination process 3102 in which slices are combined to form frames.As a result of the slice recombination process 3102, an intra-codedframe 3104 is formed for each GOP from the slices of the intra-codedguide page (PID 1) and the slices of the intra-coded video frame (PID101). Furthermore, the second to last predictive-coded frames 3106 areformed for each GOP from the slices of the skipped-coded guide page (PID11) and the slices of the predictive-coded video frames (PID 101). Theabove discussed methods can be equally applied to frame-based encodingand delivery by defining a slice as a complete frame without loss ofgenerality.

The above discussed encoding and delivery methods for PIP utilizes acombination of broadcast/demandcast traffic model where multiple videosignals are broadcast and delivered to the set top box even the viewerdoes not utilize some of the video content at a particular time. Such anapproach makes response times far more consistent, and far lesssensitive to the number of subscribers served. Typical latencies mayremain sub-second even when the subscriber count in a single modulationgroup (aggregation of nodes) exceeds 10 thousand. On the other hand, thebandwidth necessary to delivery the content increases compared to apoint-to-point traffic model. However, with the advantage of theslice-based recombinant MPEG compression techniques, the latencyreduction of broadcast/demandcast model is achieved without muchbandwidth compromise.

In addition, with a server-centric content generation and control, thetransport streams containing tremendous motion video information isdelivered and decoded directly through the transport demultiplexer andMPEG decoder without being accessible to the microprocessor, savingprocessing and memory resources and costs at set top terminal.

The multi-functional user interface supports any combination offull-motion video windows, at least one or more of these video inputscan be driven from existing ad-insertion equipment enabling the operatorto leverage existing equipment and infrastructure, including ad trafficand billing systems, to quickly realize added revenues. The discussedsystem does not have any new requirements for ad production. The ads canbe the same as are inserted into any other broadcast channels.

H. General Head-End Centric System Architecture for Encoding andDelivery of Combined Realtime and Non-Realtime Content

A unique feature of the head-end centric system discussed in previoussections (for encoding and delivery of interactive program guide,multi-functional user interfaces, picture-in-picture type ofapplications) is the combined processing of realtime and non-realtimemultimedia content. In other words, the discussed head-end centricsystem architecture can be utilized for other related applications thatcontain realtime and non-realtime content in similar ways with theteachings of this invention. For further clarification, FIG. 32illustrates a general system and apparatus for encoding, multiplexing,and delivery of realtime and non-realtime content in accordance with thepresent invention including: a non-realtime content source for providingnon-realtime content; a non-realtime encoder for encoding thenon-realtime content into encoded non-realtime content; a realtimecontent source for providing realtime video and audio content; arealtime encoder for encoding the realtime video and audio content intoencoded realtime video and audio; a remultiplexer for repacketizing theencoded non-realtime content and the encoded realtime video and audiointo transport packets; and a re-timestamp unit coupled to theremultiplexer for providing timestamps to be applied to the transportpackets in order to synchronize the realtime and non-realtime contenttherein.

FIG. 32 is a block diagram illustrating such a system forre-timestamping and rate control of realtime and non-realtime encodedcontent in accordance with an embodiment of the present invention.

The apparatus includes a non-realtime content source 3202, a realtimecontent source, a non-realtime encoder 3206, a rate control unit 3208, arealtime encoder 3210 (including a realtime video encoder 3211 and arealtime audio encoder 3212), a slice combiner 3214, a remultiplexer3216, a re-timestamp unit 3218, and a clock unit 3220.

In a preferred embodiment of the present invention, the apparatus shownin FIG. 32 are included in a head-end of a cable distribution system.

In a preferred embodiment, the non-realtime content includes guide pagegraphics content for an interactive program guide (IPG), and therealtime content includes video and audio advertisement content forinsertion into the IPG.

In a preferred embodiment, the rate control unit 3208 implements analgorithm which sets the bit rate for the output of the non-realtimeencoder 3206. Based on a desired total bit rate, the algorithm maysubtract out a maximum bit rate anticipated for the realtime video andaudio encoded signals. The resultant difference would basically give theallowed bit rate for the output of the non-realtime encoder 106. In aslice-based embodiment, this allowed bit rate would be divided by thenumber of slices to determine the allowed bit rate per slice of the IPGcontent. In a page-based embodiment, this allowed bit rate would be theallowed bit rate per page of the IPG content.

In a preferred embodiment, the re-timestamp unit 3218 receives a commonclock signal from the common clock unit 3220 and generates therefrompresentation and decoding timestamps. These timestamps are transferredto the remultiplexer (Remux) 3216 for use in re-timestamping the packets(overriding existing timestamps from the encoders 3206, 3211, and 3212).The re-timestamping synchronizes the non-realtime and realtime contentso that non-realtime and realtime content intended to be displayed in asingle frame are displayed at the same time.

In a preferred embodiment, the common clock unit 3220 also provides acommon clock stream to the set-top terminals. The common clock stream istransmitted in parallel with the transport stream.

1-20. (canceled)
 21. A method, comprising: performing, by at least onecomputing device: using graphics information to generate first videoslices for first video frames, using video content to generate secondvideo slices for second video frames, assigning a first packetidentifier to at least one of the first video slices and a differentsecond packet identifier to others of the first video slices, assigningthe second packet identifier to the second video slices, andtransmitting the first and second video slices with the first and secondpacket identifiers as assigned.
 22. The method of claim 21, furthercomprising using textual program guide data to generate the graphicsinformation.
 23. The method of claim 21, wherein the at least one firstvideo slice assigned the first packet identifier is a slice of anintra-coded video frame and the first video slices assigned the secondpacket identifier are slices of predicted video frames.
 24. The methodof claim 21, further comprising encoding the first video slices that areassigned the second packet identifier as skipped video slices.
 25. Themethod of claim 21, wherein the transmitting comprises transmitting thefirst and second video slices as an MPEG-compliant data stream.
 26. Themethod of claim 21, wherein the using the graphics information comprisesencoding the graphics information into the first video slices using afirst set of encoding parameters and the using the video contentcomprises encoding the video content into the second video slices usinga different second set of encoding parameters.
 27. The method of claim21, wherein a first subset of the second video slices comprise the videocontent as a first portion of each of the second video frames and asecond subset of the second video slices comprise null data.
 28. Themethod of claim 21, further comprising combining at least one of thefirst video slices that are transmitted with at least one of the secondvideo slices that are transmitted to form a combined video frame fordisplay.
 29. A method, comprising: generating, by at least one computingdevice, data representing (a) a first plurality of video slicesidentified by a first packet identifier that represent an intra-codedvideo frame of first content, (b) a second plurality of video slicesidentified by a different second packet identifier that represent aplurality of skipped video slices for the first content, and (c) a thirdplurality of video slices identified by the second packet identifierthat represent a plurality of video frames of second content; andtransmitting the data.
 30. The method of claim 29, wherein each of theplurality of video frames comprise the second content in a first portionof the respective video frame and null data in a second portion of therespective video frame.
 31. The method of claim 29, wherein the datacomprises an MPEG-compliant data stream.
 32. The method of claim 29,further comprising encoding the first content into at least predictedvideo frames and using the predicted video frames to generate the secondplurality of video slices.
 33. The method of claim 32, wherein the firstcontent comprises textual data and graphics data.
 34. The method ofclaim 29, wherein the first content comprises a program guide and thesecond content comprises video content.
 35. The method of claim 29,wherein the generating further comprises generating the data to alsorepresent (d) a fourth plurality of video slices identified by adifferent third packet identifier that represent an intra-coded videoframe of third content, and (e) a fifth plurality of video slicesidentified by the second packet identifier that represent a plurality ofskipped video slices for the third content.
 36. A method, comprising:receiving, over a network, data representing (a) a first plurality ofvideo slices identified by a first packet identifier that represent anintra-coded video frame of first content, (b) a second plurality ofvideo slices identified by a different second packet identifier thatrepresent a plurality of skipped video slices, and (c) a third pluralityof video slices identified by the second packet identifier thatrepresent a plurality of video frames of second content; and using, by acomputing device, the first plurality of video slices, the secondplurality of video slices, and the third plurality of video slices togenerate a plurality of combined video frames for display.
 37. Themethod of claim 36, wherein each of the plurality of video framescomprise the second content in a first portion of the respective videoframe and null data in a second portion of the respective video frame.38. The method of claim 36, wherein the data comprises an MPEG-compliantdata stream.
 39. The method of claim 36, wherein the first contentcomprises a program guide and the second content comprises videocontent.
 40. The method of claim 36, wherein the network comprises anInternet Protocol based network.